1. Technical Field
The present disclosure relates to various embodiments for transitioning from a first site to a deep link state at a merchant destination site, the deep link state enabling the user to make a purchase of a product without manually entering in payment data or address data via the use of a browser payment request application programming interface between a browser and the merchant site.
2. Introduction
This application addresses a number of issues related to simplifying and managing on-line purchases of products and navigation between sites on the Internet. Other issues addressed herein and covered in related patent applications are also discussed. This introduction may include a discussion of novel features and should not be considered as admitting that any concept discussed in this section is prior art.
The first issue addressed herein is in the context of one-click purchasing options and relates to resolving purchasing concerns of a potential buyer. Purchasing concerns can include complicated shopping cart models which require too much data (payment account, address, name, etc.), particularly on a mobile device, causing people to abandon the cart, unselected product specifications, or parameters, such as size or color for clothing, or amount of memory for an electronic device. Other purchasing concerns can include bad reviews about a product, or articles that reflect poorly on a merchant. Another concern can include resolving questions about a purchase prior to finalizing the purchase. Purchasing concerns of the buyer can include anything related to a product, service, merchant or any other topic. Thus, it would be desirous to enable an approach of transitioning to a dialog about a product to resolve purchasing concerns, finalizing the parameters and then efficiently confirming a payment. The claims in the present case address this issue.
Another issue addressed herein is how to easily transition a user from a search engine or browser site to a destination site. One effort to make this transition was provided by the omnikey feature of Safari. Using the omnikey extension, Safari users type in an indicator of what alternate site they want to use for processing input. For example, in an input field, a user would type “amazon headphones” which would instruct the algorithm processing the input to search amazon.com for “headphones” and return the result. The problem with this approach is that it is likely easier to click on an amazon tab and type “headphones” in the Amazon search field than it is to type “amazon” at the beginning of the search. Further, to tell the search engine that the user is not wanting to transition to amazon, the user would have to begin the search with an exclamation point “!” which forces regular searches. Using such a feature where most user input is likely involving regular searches according to the default search engine, might require the user to often begin searches with “!”. Thus, this effort at transitioning users to other sites is still problematic.
An additional issue relates to the long-standing problem of requiring users to enter payment data such as credit card information and a user address when making a purchase. Some sites like Amazon.com provide a “one-click” purchasing option but those simplifications are only available in the controlled Amazon.com environment. For all other merchants, users must enter payment data which is cumbersome. Mobile users outside of Amazon.com still need to include and enter in much information which reduces the number of conversions when making purchases on line either on the desktop or mobile devices.
The present disclosure also addresses an issue in the art that arises through the use of buy buttons on disparate platforms. No part of this introduction is meant to characterize “prior art”, as the present application claims priority to applications that discloses various implementations of buy buttons on search engines, social media, and so forth. Again, none of the discussion in this application should be considered as the applicant admitting any subject matter herein is prior art.
Given the availability of buy buttons on such sites as google.com, facebook.com, instagram.com, pinterest.com, bing.com, yahoo.com, youtube.com, amazon.com and twitter.com a specific challenge arises in terms of tracking purchases. A user may make a purchase of a first product on facebook.com and the next day purchase a second product on google.com. To enable such purchases, sites like google.com maintain purchase information such as credit card or payment account information. Optionally, an interface with PayPal® or Apple Pay is provided such that purchases can be easily processed. While buy buttons are expanding, there is no existing mechanism of harmonizing or organizing purchases such that users can easily manage purchases. A user may forget where a purchase was made and may feel frustrated when they cannot manage purchases or review their purchase history. For closed aggregated merchant sites like www.amazon.com, purchases are controlled through a single site with multiple merchants making their products available. The ability to manage a user account and history of purchases on such a site is considerably easier.
However, the goal of buy buttons on various sites is to enable purchases in those “micro-moments” when a person using social media such as Facebook or Instagram, and see something they might want to buy. The benefit of incorporating a buy button into traditionally non-merchant sites is to take advantage of easy purchasing from sites where people spend time, such as search engines like google.com and social media sites. However, presenting buy options at non-merchant sites to take advantage of such micro-moments introduces the difficulty of managing purchases spread across uncoordinated, disparate sites.